Quick-Connection for Brokered Engagements

ABSTRACT

Described are techniques for accessing a brokerage system for providing broker services to consumers from various service providers. A graphical user interface renders a plurality of controls that when selected by a consumer, sends a request to consult with a service provider of a type associated with the corresponding one of the plurality of controls. Upon receiving the request a second graphical user interface is sent to enable the user to provide information to a service provider for use during a consultation with a service provider of the type associated with the corresponding one of the controls.

This application claims priority under 35 U.S.C. §119 to U.S.Provisional Patent Application Ser. No. 61/753,528, filed Jan. 17, 2013,and entitled “Processing for Brokered Engagements”, the entire contentsof which are hereby incorporated by reference.

BACKGROUND

The present disclosure is directed to connecting consumers with serviceproviders.

Systems have been developed to connect consumers and their providersover the Internet and the World Wide Web. Some systems use e-mailmessaging and web-based forms to increase the level of connectivitybetween a member of a health plan and his assigned health care provider.The consumer sends an e-mail or goes to a website that generates andsends a message (typically an e-mail or an e-mail type message) to alocal provider. These types of services have been broadly referred to as“e-visits.” Other health care solutions include technologically advancedtelephone communication solutions that use advances in voicecommunication and data transmission technology to interconnect medicalprofessionals with patients.

SUMMARY

According to an aspect, a computer-implemented method includes acomputer-implemented method including generating a first graphical userinterface for accessing a brokerage system for providing broker servicesto consumers from service providers, the graphical user interfacerendering a plurality of controls that when selected by a consumer,sends a request to consult with a service provider of a type associatedwith the corresponding one of the plurality of controls, sending by theone or more computers the graphical user interface to a device used bythe consumer, receiving the request, and sending to the consumer asecond graphical user interface to enable the user to provideinformation to a service provider for use during a consultation with aservice provider of the type associated with the corresponding one ofthe controls.

According to an aspect, a computer program product tangibly stored on acomputer readable storage device for providing broker services toconsumers and service providers, the computer program product comprisinginstructions for causing a computer to generate a first graphical userinterface for accessing a brokerage system for providing broker servicesto consumers from service providers, the graphical user interfacerendering a plurality of controls that when selected by a consumer,sends a request to consult with a service provider of a type associatedwith the corresponding one of the plurality of controls, send thegraphical user interface to a device used by the consumer, receive therequest, and send to the consumer a second graphical user interface toenable the user to provide information to a service provider for useduring a consultation with a service provider of the type associatedwith the corresponding one of the controls.

According to an additional aspect, an apparatus includes a processor,memory in communication with the processor, and a computer programproduct stored on a computer readable medium for providing brokerservices to consumers and service providers, the computer programproduct comprising instructions for causing the processor to aprocessor, memory in communication with the processor, and a computerprogram product tangibly stored on a computer readable storage devicefor providing broker services to consumers and service providers, thecomputer program product comprising instructions for causing a computerto generate a first graphical user interface for accessing a brokeragesystem for providing broker services to consumers from serviceproviders, the graphical user interface rendering a plurality ofcontrols that when selected by a consumer, sends a request to consultwith a service provider of a type associated with the corresponding oneof the plurality of controls, send the graphical user interface to adevice used by the consumer, receive the request, and send to theconsumer a second graphical user interface to enable the user to provideinformation to a service provider for use during a consultation with aservice provider of the type associated with the corresponding one ofthe controls.

The following are some of the features within the scope of the aboveaspects.

The types are different types of providers. Selecting a control in thefirst user interface that allows a user to toggle between a quickconnect mode of use of the graphical user interface and a mode of usethat lists providers.

One or more of the following advantages may be provided by one or moreof the above aspects. Consumers can engage with the system using variousmodalities, including registered user, guest user and anonymous user. Inparticular an anonymous user modality is very useful for those types ofindividuals that may have serious issues, but which are generallyreluctant to discuss issues with strangers.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 is a diagrammatic view of an arrangement including a brokeragesystem.

FIGS. 2A and 2B are flow charts useful in understanding next consumerprocessing in a brokerage service.

FIG. 3 is block diagram of an availability process.

FIG. 4 is a block diagram of an alternative availability process.

FIG. 5 is a block diagram of a record.

FIGS. 5A and 5B are block diagrams of queue structures.

FIG. 6 is a screenshot of a graphical user interface for a welcomescreen.

FIG. 7 is a screenshot of a graphical user interface for an availabilitymanagement screen.

FIG. 8 is a block diagram of a queue structure.

FIG. 9 is a flow chart for assigning providers based on providernetworks/provider practices.

FIG. 10 is a screenshot of a quick-connect graphical user interface.

FIG. 11 is a flow chart for assigning providers based on thequick-connect graphical user interface.

DETAILED DESCRIPTION

Overview

The system described below provides an integrated information andcommunication platform that enables consumers of services to accessservice providers to consult and to carry out such consultations in anefficient manner. Consumers are able to consult with an expert serviceprovider even when the two parties are geographically separated. Thisintegrated platform is referred to as a brokerage system (or dependingon the context brokerage service).

Referring now to FIG. 1, an exemplary networked computer system 10 forengaging a consumer in a brokered consultation with a service providerincludes a computerized system or server 12 for processing requests fromconsumers 14 at client systems 14 a to engage with providers 16 atprovider systems 16 a. The networked computer system 10 implements abrokerage service embodied as web-based engagement brokerage. Thenetworked computer system 10 includes a web server 18 to receive on-lineweb-based requests and which provides web-based communication channelsbetween a provider and a consumer using a web browser or the like.

The server 18 receives a request for a consultation. The request isparsed to identify the particular ailment or concern, etc. of thepatient 14. The server 12 includes an availability or presence trackingmodule 26 for tracking the availability of the service providers 16.Availability or presence of service providers is tracked actively orpassively.

In an active system, one or more of the service providers 16 provides anindication to the server 12 that the one or more service providers areavailable to be contacted by consumers 14 and an indication of the modeby which the provider may be contacted. In some examples of an activesystem, the provider's computer, phone, or other terminal deviceperiodically provides an indication of the provider's availability(e.g., available, online, idle, busy) to the server 12 and a mode (e.g.,text, voice, video, etc.) by which he can be engaged.

In a passive system, the server 12 presumes that the service provider 16is available by the service provider's actions, including connecting tothe server 12 or registering the provider's local phone number with thesystem. In some examples of a passive system, the server 12 indicatesthe provider 16 to be available at all times until the provider logsoff, except when the provider is actively engaged with a consumer 14.

The server 12 also includes one or more processes in addition to thetracking module 26, such as a scheduling module 28. The server 12accesses one or more databases 27. The components of the server 12 andthe web server 18 may be integrated or distributed in variouscombinations, as is commonly known in the art.

The networked computer system 10 allows a consumer 14 to communicatewith a provider 16. The consumer 14 and provider 16 connect to theserver 12 through a website or other interface on the web server 18using client devices 14 a and 16 a, respectively. Client devices 14 aand 16 a can be any combination of, e.g., personal digital assistants,cell phones, computer systems, media-player-type devices, and so forth.The client devices 14 a and 16 a enable the consumers 14 to input andreceive information as well as to communicate via video, audio, and/ortext with the providers 16.

At the instant a consumer 14 desires to connect and communicate with aprovider, the server 12 determines whether that provider is available.If that particular provider 16 is available, the server 12 assesses thevarious modes of communication that are available forwards connectioninformation of the consumer 14 to the service provider 16 through one ormore common modes of communication. The system selects a mode ofcommunication to use based in part on the relative utility of thevarious modes.

A mode of engagement has both the consumer 14 and the provider 16 useweb-based consoles, as this allows each of the other modes to be used asneeded. For example, consumers and providers may launch chat sessions,voice calls, or video chats from within a web-based console like thatshown in FIG. 2A, below. A web based console also provides on-demandaccess to records, such as the consumer's medical history, and otherinformation. If only one of the participants in an engagement has accessto a web console, the server 12 connects that participant's console towhatever form of communication the other party has available. Forexample, if the consumer is on the phone and the provider is using a webbrowser, the server 12 may connect the consumer's phone call to a VoIPsession that the provider can access through the web. If the provider 16is not available, the server 12 identifies other available providers 16that would meet the consumer 14's needs. The server 12 enables theconsumer 14 to send a message to the consumer's chosen provider.

The server 12 includes an access control facility 30 that manages andcontrols whether a particular consumer 14 can access the networkedcomputer system 10 and what level or scope of access to the features,functions, and services the networked computer system 10 will provide.The server also includes next consumer processing 30 a that selects thenext consumer according to an algorithm that manages provider queues,but that allows a provider to access the next consumer at various stagesof the provider's interaction with the server. The server also includesavailability management 30 b processing that allows the provider tocontrol availability across provider networks and practices as will bediscussed below.

Provider networks are groups of affiliated provider practices and/oraffiliated service providers. However, not all provider practices needbe associated with a provider network. For example, individual serviceproviders are also able to register and enroll with the system.Individual service providers are independent service providers notaffiliated with a provider network and need not be a provider practice.Thus in the example of FIG. 7 if the particular provider was doingbusiness under her own name her name would appear in the dashboard.

Examples of provider networks are entities that sponsor/host instancesof the on-line care brokerage system, examples of which are insurancecompanies, whereas examples of provider practices are individualemployers or independent practices of providers such as physicianpractices or hospitals, clinics etc. that affiliate with a particularprovider network. In some instances, some of the types of entities thatare provider practices as stated above could sponsor/host instances ofthe on-line care brokerage system and thus be a provider network. One ofthe significant distinctions between an entity that is viewed as aprovider network and one that is viewed as a provider practice is thatthe provider network is responsible for providing the on-line carebrokerage infrastructure either directly or by a hosting relationshipwith another entity and also is responsible for recruiting a supply ofservice providers.

One advantage that the brokerage provides is that the brokerageconstantly monitors the availability of a provider for an engagement.Thus, consumers receive relatively quick attention to address theirquestions or concerns. The server 12 can cause a communication channelto be established between the consumer and the provider via a webbrowser or the like. The server 12 identifies service providers 16 thatare available at any given moment to communicate with a consumer about aparticular product, service, or related topic or subject, for example, amedical condition.

In order to achieve such a level of availability, the networked computersystem 10 assimilates the discretionary or fractional availabilitywindows of time offered by individual providers at stations 16 a into acontinuous availability perception by consumers. Consumers will havelittle expectation that the same provider will be constantly available,rather, they expect that some provider will be available.

By way of illustration, the networked computer system 10 servicespatients that are members of healthcare plans. For example, the serviceproviders 16 may be physicians, and the service consumers 14 may bepatients. The service providers and service consumers may also belawyers and clients, contractors and homeowners, or any othercombination of a provider of services and a consumer of services.

The system enables the consumer to search for providers that areavailable at the time the consumer is searching, and enables theconsumer to engage a provider on a transactional basis or for a one-timeconsultation. A consumer can use the system for various purposes, suchas a consultation or second opinion. An example of details of abrokerage system is discussed in my U.S. Pat. No. 7,590,550 entitled:“Connecting Consumers with Service Providers”, the contents of which areincorporated herein in its entirety.

Referring now to FIG. 2A, next patient processing 30 a for use in thenetworked computer system 10 is shown. In an embodiment, patients send42 requests for services to the server 12. The requests may includevarious information such as patient identification, health planinformation, plan sponsor, etc. The request is sent to the networkedcomputer system 10 and received 52 by the server 12 for access to anonline-care program offered by the system 10. The server 12 finds (notshown) a suitable provider based on attribute matching or assigns apatient to a provider queue with the lowest number of patients waiting.The server 12 places an entry for the patient in a queue discussedbelow.

The server also receives 54 at a time asynchronous to the requests(indicated by dashed line) a log-in from a provider. The servergenerates 56 a service provider graphical user interface as welcomescreen, having a next patient control (FIG. 6). This welcome screen is atop level screen in a set of user interfaces (FIGS. 6, 7) that permit aprovider to access the server 12 to manage the provider's experiencewith the brokerage system 10.

The system sends 58 the welcome screen (see FIG. 5) to the provider, andwaits for a selection from the provider. When an action is received bythe system, the server determines 60 the action. If the action is nextpatient, (the provider selected the next patient control) the server 12executes 62 an algorithm to determine the next patient from patientrecords in the provider's queues. The server 12 retrieves 68 the nextpatient record and prepares a session 69 by determining from informationreceived from the patient what services will be required during thesession, determining eligibility for services, etc. The server 12establishes a communication channel between the patient and theprovider. When the action is not next patient, the server 12 continues62 with welcome processing.

Referring now to FIG. 2B, when the server 12 receives any otherselection from the welcome screen, the server 12 determines 80 theaction received. For example from the welcome screen, the server canreceive a provider's selection to manage availability 82. The servergenerates 84 a service provider availability management interface (FIG.6) with the next patient control and sends the interface to theprovider's system. The provider manages availability and at that screenat any time can also select the next patient or can select anotherpatient. Alternatively, the server 12 receives 90 from the provider'ssystem a selection from the welcome screen that causes the server 12 tocontinue to the provider's home page (referred to as a “reverse providerpractice graphical user interface”) for particular providernetworks/practices, as discussed in my co-pending published, application“Reverse Provider Practice” Pub. No. US-2012-0284362-A1 assigned to theassignee of the present invention and incorporated herein by referencein its entirety. Continuing to the provider's home page allows theprovider to access graphical user interface for individual providernetworks that display the types of health services that are offered bythe sponsor to consumers.

In some implementations, the server generates 92 a service provider homepage interface for that provider with the home page also including thenext patient control. The provider accesses the home page and interactswith the server 12 though the home page.

At some point, the provider will engage with a consumer (patient). Aselection can be made from one of the interfaces sent by the server 12such as the service provider availability management interface (FIG. 6)or the service provider home page interface (not shown). If theselection is a next patient, (the provider selected the next patientcontrol) the server 12 executes 93 the next patient algorithm todetermine the next patient from patient records in the provider'squeues. The server retrieves 95 the next patient record (and prepares asession not shown). The server 12 then establishes 98 a communicationchannel between the patient and the provider to enable the patient toengage 99 with the provider. When the selection is not next patient, theserver 12 retrieves 96 the provider selected patient and the serverestablishes the channel 98.

The server 12 prepares a user session (not shown) by determining frominformation received from the patient what services will be requiredduring the session (see 69, above FIG. 2A). In one example, the server12 retrieves those services that the sponsor has chosen to be offeredservices. A sponsor selects offered services based on various factorsincluding costs and usage data. Usage data is indicative of an amount ofhealth services being consumed, by consumers, for a particular type ofhealth service. The various factors can also gender, age, health statusof the insured, as well as the availability of the services, cost of theservices and how often the services were selected by segments of insuredgroups of individuals. Also the server can prepare payment information,e.g., co-pays and the like.

From the provider's viewpoint, the provider chooses a patient from avirtual waiting room. The virtual waiting room can include not onlyregistered user patients, but other patients such as patients that areguest or anonymous users. The server 12 facilitates sessions between thepatient and the provider by establishing the real time communicationchannel between devices/systems used by the patient and the providerwith the channel being established through the server 12. In otherimplementations, the server 12 causes establishment of the communicationchannel between devices/systems by a join of communication channels orby sending the provider connection information to call the patient in acall back mode.

Referring now to FIG. 3, the server 12 tracks 100 the availability ofproviders 16 and in some embodiments, on-line consumers 14. When aprovider 16 logs 102 into the networked computer system 10, the provider16 indicates 104 (such as by setting a check box or selecting a menuentry or by responding to a voice prompt) to the tracking module 26 thathe or she is available to interact with consumers 14. The provider 16can also indicate 106 a to the tracking module 26 (such as by setting acheck box or selecting a menu entry or by responding to a voice prompt)the modes (e.g., telephone, chat, video conference) by which a consumer14 can be connected to the provider 16.

The server 12 also includes availability management processing 30 b(discussed in FIG. 4) to access 105 the availability managementinterface.

Alternatively, the tracking module 26 determines 106 b the capabilitiesof the terminals 14 a and 16 a the consumer 14 and the provider 16 useto connect to the system (for example, by using a terminal-based programto analyze the hardware configuration of each terminal). Thus, if aprovider 16 connects to the networked computer system 10 by a desktopcomputer and the provider has a video camera connected to that computer,the tracking module 26 determines that the provider 16 can be engaged bytext (e.g., chat or instant messenger), voice (e.g., VoIP) or videoconference. Similarly, if a provider 16 connects to the system using ahandheld device such as a PDA, the tracking module 26 determines thatthe provider 16 can be engaged by text or voice, whereas, if theconsumer connects to the networked computer system 10 via a telephonefor a telephonic engagement the provider will reply with a telephonecall to the consumer. The tracking module 26 can also infer 106 c aprovider's availability and modes of engagement by the provider'spreviously provided profile information and the terminal device throughwhich the provider connects to the system. The availability informationcan be transferred 108 to scheduling.

Providers participating in the brokerage system 10 can have severalstates of availability at different times. States in which the providermay be available include “on-line”, in which the provider is logged-inand can immediately accept new engagements in any mode, “on-line(busy)”, in which the provider is logged-in but is currently occupied inanother engagement, and “scheduled”, in which the provider is offlinebut is scheduled to be online at a designated time-point and canpre-schedule engagements for it. A provider can also be not-logged inand thus unavailable.

Also, while not online, the provider can take messages as in offlinestate. Thus, another state includes off-line, in which the provider isnot logged in but can take message-based engagements (i.e., asynchronousengagements), out-of-office, in which the provider is not acceptingengagements or messages, and “on call”, in which the provider is offlineand can be paged to go to on-line status by the brokerage network iftraffic load demands it (in some examples, consumers see this state asoffline).

The operating business model for the provider network employs aremuneration scheme for affiliated providers that helps assure that theconsumers can find providers in designated professional domains in theonline mode. For example, selected providers can be remunerated forbeing in the on-call mode to encourage on-line availability in case oflow discretionary availability by other providers in their professionaldomain. On-call providers are also called into the on-line state whenthe fraction of on-line (busy) provider's domain exceeds a certainthreshold.

Referring now to FIG. 4, provider availability management 30 b is shown.In certain embodiments, the provider is presented with a user interface(FIG. 6) that enables the provider to selectively control/manage his/heravailability status across provider networks and provider practices ofwhich the provider is affiliated with. Thus, after log-in 112, theprovider sends (not shown) a request to the server 12 for anavailability management interface (FIG. 6) and server receives 113 oneor more indications of the provider's availability status. The providersets 114 an availability status either for each provider practice withina provider network, or sets 115 an availability status across allprovider practices within a provider network. As the server 12 receivesprovider set availability status indications 116, the server repeats theprocess and at any juncture (such as after receiving an indication)transfers 117 the availability status information to the schedulingprocess 28.

The server 12 thus tracks the provider's availability based not only onany current engagements by the provider, but also on provider setavailability status indications over provider networks/providerpractices. The server will update the provider's status with particularprovider networks/provider practices according to selections made by theprovider. These selections will in general override default provideravailability indications set by the server 12.

Referring now to FIG. 5, a consumer (e.g., patient) record 125 is shown.This record is retrieved, e.g., from a queue consumers waiting to beserviced by a provider or from a database based on retrieving an entryfrom the queue of consumers waiting to be serviced by a provider. Therecord includes various items 125 a-n of information regarding theconsumer.

Referring now to FIG. 5A, the tracking module 26 (FIG. 1) transfers 117(FIG. 4) information about the availability of providers 16 and thecommunication capabilities of the consumers 14 and the providers 16 tothe scheduling module 28. The scheduling module 28 uses the trackinginformation to schedule providers with consumers. In some embodiments,the scheduling module 26 also uses provider set availability statusindications to either allow entries into certain queues or not dependingon the provider set status (FIG. 8).

In one embodiment, each provider, e.g., “provider-a” to “provider-n” isassociated with a queue, e.g., 120 a-120 n, respectively. The queue foreach provider is filled by the server 12 with entries (as depicted asentries 1 through i and entries 1 through m) that correspond to requestsfor consultations with a provider. More specifically, as consumersaccess the networked computer system 10 and are processed through theintake process, entries representing the consumers are produced by theserver 12 and those entries are queued.

In one embodiment, the server 12 stores the entries in queues of thoseproviders that the server 12 determines has the least number of entries,in order to balance provider utilization across the system 10, and tootherwise minimize overall response time for consumers. The server 12produces an entry for storage in one of the queues (generally 120). Theserver 12 examines the queues 120 a-120 n of all providers that aresuitable to provide a consultation with the consumer and the serverchooses the queue of a suitable provider that has the least number ofentries waiting to be processed. The queue, e.g., queue 120 a of thechosen provider (provider-a) is loaded with that entry.

To select entries from the queue, the server 12 uses in one embodiment afirst in first out priority scheme to retrieve an entry from the query.Selecting of the next patient control on one of the aforementionedgraphical user interfaces would in this scheduling algorithm chose theentry that is oldest in the queue. That is, in servicing consumerrequests, for a particular provider, the server 12 retrieves the entryof a consumer that is next to be serviced (the oldest entry in the queue120). As the provider services that consumer, the server 12 removes thecorresponding entry from that provider's queue and the server 12promotes all remaining entries in that queue such that the next entry inthe queue to be serviced will be now be the oldest entry.

However, in an alternative embodiment, the next patient algorithmapplies a priority scheme based on a priority designation of patientswith those designated as “high priority” being given precedence overlower priority designations. Any number of priority designations can beused, with three being a workable number of designations. Prioritydesignations can be based on an initial triage that is made during anintake process using either a triage algorithm or a servicerepresentative's assessment based on information obtained during intake.Many factors can be considered including, e.g., severity of conditions,degree of overuse of the brokerage system either by specific individualsor collectively by individuals in provider practices, e.g., associatedwith a sponsor (e.g., an employer/plan), specific employer and/or plan,etc. Priority can also be based on specific online practices (e.g.,patients coming in through the “Emergency Management” practice arehigher priority than the “Flu” practice). Priority can consider multipleones of those factors. For example, the priority algorithm can giveprecedence to the patient triaged with high priority based on severityof medical conditions and which is the oldest in the queue.

With the factor-based priority scheme, for servicing consumer requestsfor a particular provider, the server 12 retrieves the entry of aconsumer that is next to be serviced at a priority designation that iscurrently the highest designation having entries in the queue 120. Asthe provider services that consumer, the server 12 removes thecorresponding entry from that provider's queue and the server 12promotes all remaining entries in that queue at that designation suchthat the next entry in the queue to be serviced will be now be theoldest entry at that priority designation. When all entries have beenserviced from the queue with at that priority designation, the serverwill retrieve the entry of a consumer that is next to be serviced at apriority designation in the queue 120 that is the next lowest priority.The server 12 can also monitor the queues to insure that the queues arenot filled with high priority designations for one provider at such arate that the provider cannot service lower priority designations.

Referring now to FIG. 5B, in an alternative embodiment, the queues(generally 120′) for each provider are sub-divided or represented asplural sub-queues with each of the sub-queues corresponding to anappointment “state.” In FIG. 5B, two queues 120 a-1 to 120 a-2 and 120n-1 to 120 n-2 are shown for each of the providers, e.g., “provider-a”to “provider-n” with the sub-queues 120 a-1 to 120 a-2 and 120 n-1 to120 n-2 representing, “waiting room” and “scheduled appointments” of therespective providers “provider-a” to “provider-n.”

In this embodiment, the server using scheduling module 116, examines thequeues of all providers that are suitable to provide a consultation withthe consumer and chooses the appropriate sub-queue of a suitableprovider that has the least number of entries waiting to be processedfor the particular state, e.g., “waiting room” and “scheduledappointments.” More specifically, for “telephonic engagements” theserver loads entries into the waiting room queue of the particularprovider that has the fewest entries.

In servicing requests, for a particular provider, the server 12retrieves the entry of a consumer that is next to be serviced from thewaiting room for that provider. The next to be serviced is according tothe following priority the oldest entry in the waiting room. Inbrokerage systems that allow for telephonic generated requests withprovider call-backs the oldest entry priority would be adjusted when theserver determines that the scheduled appointment queue of the providerhas either an entry for a scheduled telephonic callback or scheduledappointment that has an scheduled appointment time that is either equalto the current time or would be within a time window where the servicingof a waiting room entry or a new request would adversely impactservicing of scheduled telephonic callback or scheduled appointmentqueued entries. For example, in some embodiments the system 10 couldallocate a set time period of, e.g., 15 minutes to service a request.Accordingly, the server 12 would not select an entry from the waitingroom queue if there was a scheduled appointment in, e.g., 10 minutes.

Telephonic engagements without any scheduling will generally be placedin and thus serviced from the waiting room sub-queue. As the providerservices a consumer from its sub-queue all remaining entries(representing other consumers) in that sub-queue are promoted such thatthe next entry in the sub-queue to be serviced will be the next oldestentry.

In another embodiment, the server 12 can execute the next patientalgorithm that applies a priority scheme based on a priority designationof patients, as discussed above. Again, the priority designations arebased on an initial triage made during an intake process consideringseveral of the above mentioned factors.

With the factor-based priority scheme, for servicing consumer requestsfor a particular provider, the server 12 retrieves the entry of aconsumer that is next to be serviced at a priority designation that iscurrently the highest designation having entries in either one of theprovider's queues 120′. As the provider services that consumer, theserver 12 removes the corresponding entry from that provider's queue andthe server 12 promotes all remaining entries in that queue at thatdesignation such that the next entry in the queue to be serviced will benow be the oldest entry at that priority designation. When all entrieshave been serviced from the queue with at that priority designation, theserver will retrieve the entry of a consumer that is next to be servicedat a priority designation in the queue 120 that is the next lowestpriority.

Referring now to FIG. 6, a graphical user interface 130 that the server12 generates and sends to a device used by the provider is shown. Thisinterface 130 can be sent after a successful provider log-in to theserver 12, e.g., as a welcome screen. Exemplary potential actions thatcan occur from the interface 130 include selection of the next patientvia next patient control 131 a, managing availability via a manageavailability control 131 b, and to continue to the provider's home page(as in co-pending published, application “Reverse Provider Practice”Pub. No. US-2012-0284362-A1) via selection of the home page control 131c. The home page allows the provider to sign into specific providernetworks. Other controls can be included in the welcome screen 130.

Referring now to FIG. 7, a graphical user interface 140 for managingprovider availability is shown. The graphical user interface 140 depictsprovider practices 142. In some embodiments the provider practices arearranged into one or more provider networks 144. Each provider will bepresented with an instance of the graphical user interface that istailored to that provider's practice. Using “provider-a” as an example,provider-a, is associated with three provider networks and severalprovider practices within each provider network.

That is, as shown in FIG. 7, “provider-a” is associated with threeprovider networks 144, HMSA'S Online Care 144 a; NowClinic 144 b; andOnline Care NY 144 c. Within each of provider networks 144 a-144 c,provider practices 142 are distributed according to their respectivemembership. In the HMSA provider network are included First Care MedicalAssociates 142 a and Second Care Medical Associates 142 b, Third CareMedical Associates 142 c and Waikiki General 142 d are among the sevenprovider practices (generally 142) under HMSA'S Online Care providernetwork. Similarly, others of the provider practices 142 are arrangedunder provider networks 144 b and 144 c.

Representations in the interface 140 for each of the provider practices(generally 142) include the following controls/regions juxtaposed eachother in a row per provider practice: a control that indicates thatthere is an un-read message (e.g., e-mail) 145 from the correspondingnetwork; a region that displays an availability indicator 146, a controlto set availability 147; a region that displays a number of consumerswaiting 148; and a region 149 that displays the highest wait time ofconsumers in the particular provider practice. Each of the providernetworks (generally 144) include the following controls: a control toset availability 150; a region 151 that displays a total number ofconsumers waiting from all provider practices 142 within the particularprovider network 144; and a region 152 that displays the highest waittime of consumers in the particular provider network.

Using HMSA'S Online Care provider network 144 a and First Care MedicalAssociates 142 a and Waikiki General 142 d provider practices to furtherillustrate, the interface 140 shows that the provider has setavailability status in First Care Medical Associates 142 a as“Available” and has set availability status in Waikiki General 142 d as“Unavailable.” HMSA'S Online Care provider network 144 a is an examplewhere the provider as chosen to set availability status individually foreach of the provider practices in HMSA'S Online Care provider network144 a, e.g., First Care Medical Associates 142 a, Second Care MedicalAssociates 142 b, Third Care Medical Associates 142 c, Waikiki General142 d and the remaining provider practices. In contrast, the Now ClinicProvider network (all available) and Online Care NY provider network(all unavailable) had the availability status of each provider practicein those provider networks set at the provider network level.

The interface 140 also includes a control 160 to allow the provider toadd a network. The control 160 when selected will cause the server 12 toretrieve from storage a listing of all networks that the provider isassociated with and will allow the provider to add a network to theinterface 140. Conversely, the interface also includes a control 162 toallow the provider to remove a network. The control 162 when selectedwill cause the server 12 to retrieve from storage the listing of allnetworks that the provider has on the interface 140 and will allow theprovider to remove a network from the interface 140. This functionalityof adding and removing networks can be accomplished using varioustechniques.

As also shown in FIG. 7, the interface 140 includes a Next Patientcontrol 164 for the entire interface 140 and Next Patient controls 166a, 166 b and 166 c for each of the provider networks 144 a to 144 c,respectively. Selection of the Next Patient control for the interface140 will select the next patient according to a selection algorithm thatis employed over all of the provider networks 144, whereas selection ofthe Next Patient control for one of the provider networks will selectthe next patient in the corresponding provider network according to theselection algorithm employed. In some embodiments, the algorithms willonly consider patients in the provider network corresponding to theselection of the Next Patient control.

As also shown in FIG. 7, because the provider has chosen to beunavailable in Online Care NY, the Next Patient control 166 c isgreyed-out as is the Next Patient control 164. The Next Patient control166 b is shown as active and the algorithm will select the next patientfrom among all of the provider practices in the Now Clinic providernetwork, whereas the Next Patient control 166 a also shown as active,however the algorithm will only select the next patient from among thoseprovider practices in the HMSA'S Online Care provider network that theprovider has set to the available status.

Referring now to FIG. 8, an alternative queue structure 180 is shown. Inthis alternative, the queues (generally 180) for each provider aresub-divided or represented as plural sub-queues with each of thesub-queues corresponding to a provider network 144 (FIG. 7). Thus, threesub-queues 180 a-1 to 180 a-3 are shown for the provider correspondingto the particular example of the interface shown in FIG. 7, andsub-queues 180 n-1 to 180 n-2 are shown for a provider “n” that has onlytwo provider networks with which the provider-n is associated, and thatis associated with a different instance (not shown) of the interface ofFIG. 7. Consumer entries in the sub-queues 180 a-1 to 180 a-3 and 180n-1 to 180 n-2 representing provider networks include a providerpractice indicator 183 that corresponds to a particular providerpractice through which the consumer accessed the brokerage system 10.The scheduling module 28 would check the provider practice indicator 183included with the entry, against the provider set availability statusindications (FIG. 7) to determine whether to assign that consumer to theprovider.

In an alternative, the sub-queues 180 a-1 to 180 a-3 and 180 n-1 to 180n-2 represent provider networks can be further sub-divided intosub-queues provider practices within a particular provider network. Inanother alternative, the sub-queues 180 a-1 to 180 a-3 and 180 n-1 to180 n-2 could be further sub-divided into “waiting room” and “scheduledappointments” states of the respective providers “provider-a” to“provider-n.”

Referring now to FIG. 9, the server 12 controls filling of the queues180 by the provider's availability status set by the provider, viainterface 140 (FIG. 7) and how incoming requests are assigned. Anincoming request either includes a choice of provider or causes theserver 12 to select the provider. When the incoming request includes aselection of provider made by the patient based on attribute matching,the server 12 will only send to the patient those providers that havesufficient matches and which have an available status of some type,e.g., currently available, waiting room etc. Receipt of the request withthe selection will cause the server 12 to add an entry into theappropriate queue of the selected service provider, according to theprovider set, availability status indications.

When the server 12 determines the provider, the server 12 assignsincoming requests to providers based on availability statuses of theproviders. Typically, each provider can be associated with manydifferent provider practices 142 in different provider networks 144.With providers having the ability to selectively control availabilitystatuses, the server 12 assigns incoming requests to providers accordingto those statuses.

The server 12 receives 192 requests for engagements with serviceproviders. The server 12 determines 194 what, if any, providerpractice/provider network the consumer that sent the request isassociated with. The server 12 searches 196 the queues for providersthat can service the consumer request, according to the determinedprovider practice/provider network, if any. For consumer requestsassociated with a provider practice/provider network only those providerqueues can be searched, whereas for consumer requests that are notassociated with any provider practices/provider networks only queues ofproviders that handle out of network/practice requests are searched.

The server 12 will assimilate a listing of all open queues (queues wherethe provider has not indicated “not available” or queues of providersthat are not logged in) according to the determined providerpractice/provider network. For those providers that can service theprovider practice/provider network associated with the request, and thatare open, the server calculates 198 for each of those providers, a totalnumber of patients waiting for each provider across all of the openqueues (queues where the provider has not indicated “not available” orqueues of providers that are not logged in) of the provider. The server12 determines 200 which of those providers have the fewest total numberof patients in all of the provider's queues. The server assigns 202 theincoming request to the provider with the fewest number of entries. Whena provider has an availability status of “not available” in either aprovider network 144 or a provider practice 142 (FIG. 7), the server 12will not assign request to the corresponding queues for that provider orconsider that provider's overall total number of waiting patients, sincethat provider cannot at that juncture service the incoming request. Inthis embodiment, the server using scheduling module 28, examines thequeues of all providers that are suitable to provide a consultation withthe consumer and chooses the appropriate sub-queue of a suitableprovider that has the least number of entries waiting to be processedfor the provider network 144 or provider practice 142.

A similar arrangement (not illustrated) can be used for servicing andselecting providers for consumer requests that are not associated withany provider practice/provider network. That is, the server calculatesfor each of those providers of open queues that can service out ofnetwork/practice requests, a total number of patients waiting for eachprovider across all of the open queues (queues where the provider hasnot indicated “not available” or queues of providers that are not loggedin) of the provider and determines those providers having the fewesttotal number of patients and assigns the incoming request to theprovider with the fewest number of entries.

In servicing requests, for a particular provider, the system retrievesthe entry of a consumer that is next to be serviced from the queue forthat provider according to whether the provider manually selected apatient or selected one of the aforementioned instances of the NextPatient control according to the algorithm employed by the server forselection of a next patient.

As noted, the server 12 includes access control facility 30 thatcontrols how consumers 14 access the system and to what extent or levelthe services provided by the system are made available to consumers. Theserver 12 also stores and provides access to consumer information (e.g.,contact information, credit and financial information, credit cardinformation, health information, and other information related to theconsumer and the services purchased or otherwise used by the consumer)and provider information (e.g., physician biographies, product andservice information, health related content and information and anyinformation the provider or the health plan wants to make available tomembers) and the access control facility 30 can prevent unauthorizedaccess to this information. In some examples, the server 12 exports theconsumer information for use in a provider's office or other facility.

In some embodiments, consumers may select providers according toattributes of the provider, such as a geographical area where theprovider is located or which professional organizations have accreditedthe provider (e.g., whether a doctor has board certification incardiology). Any metrics within the provider profile can be used todefine a list of providers that meet the consumer's preferences. In thiscase, the system will use the consumer's selection to override the leastused scheme for populating provider queues.

Referring now to FIG. 10, a quick-connect graphical user interface 210for accessing various provider types though a brokerage system is shown.The quick connect graphical user interface 210 is generated by theserver 12 and sent to a user device, e.g., a tablet computing device212, as illustrated, a computer, and the like and the quick-connectgraphical user interface 210 is used to quickly access and connect tothe brokerage system 10. The quick-connect graphical user interface 210is a minimal interface. The quick-connect graphical user interface 210renders a plurality of controls 216 that when selected by a consumer,sends a request to consult with a service provider of a type associatedwith the corresponding one of the plurality of controls.

For example, as shown in FIG. 10, the types of providers are apharmacist, a nutritionist, an internist, and a beautician. This is anexample of a quick-connect graphical user interface 210 that allowsquick connection with disparate provider types via a general brokeragesystem that handles brokering of provider availability across variousdifferent un-related types of providers. Selection of one of thesecontrols 246 automatically launches a request that the server 12 uses tofind the next available provider of the type selected. Upon receivingthe selection and generating the request, the server 12 sends to theconsumer device a second graphical user interface (not shown) to enablethe consumer to provide information to a service provider for use duringa consultation with a service provider of the type associated with thecorresponding one of the controls 216.

In some embodiments, the controls 216 represent different specialtieswithin a type of provider, e.g., an internist, ophthalmologist, andobstetrician/gynecologist with the type of physician. In otherembodiments, the controls 216 are of different sub-specialties within aparticular specialty, e.g., an endocrinologist, a gastroenterologist,and a cardiologist within the specialty of internal medicine.

The quick-connect graphical user interface 210 also includes a set ofcontrols 218 in the quick-connect user interface 210 that allows a userto toggle between a quick connect mode of use (as illustrated by thequick-connect item being un-shaded in graphical user interface 210) anda provider selection mode that presents another graphical user interfacethat lists providers (not shown) but as discussed in U.S. Pat. No.7,590,550 mentioned above.

Referring now to FIG. 11, the server 12 accesses 260 queues according toprovider type, in response to receiving a selection of a provider typefrom the quick-connect graphical user interface 240 (FIG. 10). Thislaunches a request for the provider type to cause the server 12 toselect 254 the provider of that type. In some embodiments, the selectionof a provider type from the quick-connect graphical user interface 240will launch an interface (not shown) that allows for a selection ofprovider made by the consumer based on attribute matching. The server 12will only send to the consumer those providers that have sufficientmatches to attributes and which have an available status of some type,e.g., currently available, waiting room etc. Receipt of the request willcause the server 12 to add 256 an entry into an appropriate queue of theselected service provider.

In other embodiments, the server 12 applies the processing of FIG. 5where the server stores the entries in queues of those providers of theappropriate type that the server 12 determines has the least number ofentries, in order to balance provider utilization across the system 10,and to otherwise minimize overall response time for consumers, asgenerally discussed above.

With the quick-connect graphical user interface 240 plural queuestructures are provided according to a like plurality of provider types.Thus, the queue arrangements of FIG. 5A, 5B or 8 for example arereplicated according to the number of provider types, meaning that forwhatever queue scheme and provider type scheme are employed there arequeues for providers for each of the types associated with the controlson the interface. Thus, using FIG. 5B, the queue structure shown in FIG.5B would be replicated for each type of provider.

Modes of Engagement

Telephonic callbacks—Consumers who wish for a telephonic consultationwith a provider may use a traditional telephone to enter information, asdiscussed above, and hangs up and waits for a call-back from a suitableprovider, as also discussed above. Providers are sent informationconcerning the consumer in order to understand the consumer's issue anda telephone number by which the provider contacts the consumer.

In some embodiments of the networked computer system 10, the networkedcomputer system 10 allows consumers to engage provider's e.g., healthprofessionals “on demand” based on provider availability. Theseengagements can be established in various ways as described in the abovementioned patent. These types of engagements include:

Passive browsing—Reference health content is accessed on the brokerage'swebsite. The website can support the use of licensed content packagesfrom other vendors to meet the variable preferences of health plans. Forexample, key content vendors include Healthwise™, ADAM™, Mayo Clinic™and HealthDay™. Content libraries provided by such vendors offer acombination of articles, imagery, interactive tutorials and relatedtools that allow consumers to access content relevant for their healthissues. Many health plans and major employers already possess a licensefor the use of one of these content packages.

Health Risk Assessments—The system acquires information from consumersthrough automated interaction (e.g., rules-based interaction) in orderto crystallize their needs (e.g., medical risks) and better direct them.Assessments span from general health to very specific medical conditionsand follow a path of questioning that dynamically tailors itself basedon information already retrieved (e.g., using predefined rules). Asassessments progress, the system constructs engagement suggestions thatthe consumer can exercise. Each suggestion represents both the questionto the provider and the type of provider appropriate to answer it.Consumers may choose to simply launch such engagements or apply theirown discretion as to the phrasing and the selection of the recipientprovider. This is discussed in more detail below in the context of theconsumer advisor.

Asynchronous correspondence—The lowest level of true providerinteraction is by way of secure messaging. The question or topic of theengagement is sent to a selected provider (whether online or not) andcan be answered by this provider at her leisure. Turnaround times aremonitored by the system and are part of the credentials of the providerused for her selection by consumers. The system informs the consumeronce a response has been received and can allow the consumer to redirectthe question if he needs more urgent response time. For example, typicaltypes of asynchronous correspondence include e-mail, instant messaging,text-messaging, voice mail messaging, VoIP messaging (i.e., leaving amessage using VoIP), and paper letters (e.g., via the U.S. PostalService).

Synchronous correspondence—Several forms of synchronous correspondenceallow the consumer and the provider to engage in real-time discussions.

Synchronous text correspondence—This may be referred to as a “Chat”module where both sides of the engagement type their entries in responseto each others' entries. The form of communication may be entirely textbased but is still a live communication. Examples include instantmessaging and SMS messaging.

Web-based teleconferencing—The use of broadband network connectionsallows for real-time voice transmission over the Internet in what isreferred to as full duplex (i.e., both voice channels are open at thesame time). Consumers can opt to have a voice conversation with theirproviders using, for example, their computer's speakers and microphone.Web-based teleconferencing may use VoIP, SIP, and other standard orproprietary technologies.

Telephonic conferencing—Consumers who wish for a direct telephoniccommunication with a provider or who are not comfortable using theircomputer may use a traditional telephone for interaction with aprovider. The consumer may use a dial-in number and an access code thatconnects him to the brokerage's servers. Providers are linked to theservers via VoIP, other data-network-based voice systems, or their owntelephones. Telephonic conferencing may also allow consumers to request“call me now” functions, in which the provider calls the consumer(directly or through the brokerage).

Video conferencing—The system can support video conferencing to allowconsumers to exhibit physical findings to providers if such disclosureis needed. Consumers and providers may also simply prefer face-to-facecommunication, even if remote. Small digital cameras, referred to aswebcams, attached to or built in to personal computers or laptops can beused for this purpose. Video conferencing can be provided by standardsoftware or by custom software provided by the brokerage. Alternatively,dedicated video conferencing communication equipment or telephones withbuilt-in video capabilities can be used.

Semi synchronous correspondence—Some engagements of a consumer with anonline provider include both synchronous and asynchronous interactions.Part of the engagement takes place by immediate messaging between thetwo, but the provider may ask the consumer to take occasionalasynchronous assessments if, for example, a generic line of question isdesired. This allows the provider to operate more than one consumerengagement at a time while each consumer is constantly engaged. Forexample, semi-synchronous correspondence includes a combination ofe-mail, instant messaging, test messaging, voice calls and mailmessaging, and VoIP calls and VoIP messaging.

Interactive Voice Response Engagements

Interactive Voice Response (IVR) systems allow for the deployment ofinteractive audio menus over the phone. The caller can navigate betweenoptions, listen to data-driven information, provide meaningful input,and engage system functions. IVR engagements extend the reach of thesystem to the telephone as a portable consumer interface to launch anengagement in addition to the Web-based interface. Consumers select apin code on the application to authenticate their identity if they callin. Several types of engagements can be carried out through an IVRsystem using suitable logic such as described in the patent. For dial-inengagements, the consumer calls in and invokes a telephonic engagementwith an available provider. The IVR system extends the consumer'sability to select a provider to the phone so that the consumer'sinteraction resembles one carried out on the Web.

The IVR system can also be used proactively to pursue consumers who needa follow-up. At the time of a follow-up, the system recalls the providerwith whom the follow-up is desired (or the type of provider in case thefollow-up is not restricted to a specific provider), identifies that theprovider is available for an engagement, and attempts to contact theconsumer over the phone to establish a connection for the engagement.Once contacted, the consumer can decline or ask postpone the call. Ifthe consumer takes the call, the connection is made. When consumers arepursuing an engagement with a provider that is either busy or currentlyoffline, the IVR system allows the consumer to park in a standby modeuntil the provider is available. When the provider is available, thesystem calls the consumer, identifies the provider to the consumer, andverifies that the consumer is still interested in pursuing the call withthe provider. If the consumer is still interested, an engagement isconnected.

In addition to launching engagements, the IVR interface allows consumersto interact with other services offered by the brokerage. For example,consumers can instruct the system to fax a transcript of theirinformation to a fax machine that the consumer identifies by keying inor speaking its phone number. Using such a function, a consumer makeskey information available to, e.g., emergency room personnel or to aprovider in an office visit, without the need to plan, collect, print,and carry the information to that encounter.

IVR hardware is readily available from telecommunication vendors and canbe programmed to operate in the context of the brokerage framework.Authentication is provided through a PIN number or by other standardmethods.

The consumer information collected by the intake process may be storedin the databases 27 as part of the overall brokerage system. In someexamples, the consumer information is protected and secured fromunauthorized access and in compliance with the various legalrequirements for storing private consumer information (for example,HIPPA governs access to an individual's health care information). Thedatabase 27 may also the process logic and rules data including thebusiness logic of an application or rules for a rules engine thatimplements the consumer advisor module.

The brokerage extends the result of any engagement to a physical pointof care or service provider to allow continuation or escalation ofservices beyond those provided in the electronic encounter.

Embodiments can be implemented in digital electronic circuitry, or incomputer hardware, firmware, software, or in combinations thereof.Apparatus of the invention can be implemented in a computer programproduct tangibly embodied or stored in a machine-readable storage devicefor execution by a programmable processor; and method actions can beperformed by a programmable processor executing a program ofinstructions to perform functions of the invention by operating on inputdata and generating output. The invention can be implementedadvantageously in one or more computer programs that are executable on aprogrammable system including at least one programmable processorcoupled to receive data and instructions from, and to transmit data andinstructions to, a data storage system, at least one input device, andat least one output device. Each computer program can be implemented ina high-level procedural or object oriented programming language, or inassembly or machine language if desired; and in any case, the languagecan be a compiled or interpreted language.

Suitable processors include, by way of example, both general and specialpurpose microprocessors. Generally, a processor will receiveinstructions and data from a read-only memory and/or a random accessmemory. Generally, a computer will include one or more mass storagedevices for storing data files; such devices include magnetic disks,such as internal hard disks and removable disks; magneto-optical disks;and optical disks. Storage devices suitable for tangibly embodyingcomputer program instructions and data include all forms of non-volatilememory, including by way of example semiconductor memory devices, suchas EPROM, EEPROM, and flash memory devices; magnetic disks such asinternal hard disks and removable disks; magneto-optical disks; andCD_ROM disks. Any of the foregoing can be supplemented by, orincorporated in, ASICs (application-specific integrated circuits).

Other embodiments are within the scope and spirit of the descriptionclaims. For example, due to the nature of software, functions describedabove can be implemented using software, hardware, firmware, hardwiring,or combinations of any of these. Features implementing functions mayalso be physically located at various positions, including beingdistributed such that portions of functions are implemented at differentphysical locations.

What is claimed is:
 1. A computer-implemented method comprising:generating a first graphical user interface for accessing a brokeragesystem for providing broker services to consumers from serviceproviders, the graphical user interface rendering a plurality ofcontrols that when selected by a consumer, sends a request to consultwith a service provider of a type associated with the corresponding oneof the plurality of controls; sending by the one or more computers thegraphical user interface to a device used by the consumer; receiving therequest; and sending to the consumer a second graphical user interfaceto enable the user to provide information to a service provider for useduring a consultation with a service provider of the type associatedwith the corresponding one of the controls.
 2. The method of claim 1,wherein the types are different types of providers.
 3. The method ofclaim 1, further comprising: receive a message by a user selecting acontrol in the first user interface that allows a user to toggle betweena quick connect mode of use of the graphical user interface and a modeof use that lists providers.
 4. A computer program product tangiblystored on a computer readable storage device for providing brokerservices to consumers and service providers, the computer programproduct comprising instructions for causing a computer to: generate afirst graphical user interface for accessing a brokerage system forproviding broker services to consumers from service providers, thegraphical user interface rendering a plurality of controls that whenselected by a consumer, sends a request to consult with a serviceprovider of a type associated with the corresponding one of theplurality of controls; send the graphical user interface to a deviceused by the consumer; receive the request; and send to the consumer asecond graphical user interface to enable the user to provideinformation to a service provider for use during a consultation with aservice provider of the type associated with the corresponding one ofthe controls.
 5. The product of claim 4 wherein the types are differenttypes of providers.
 6. The product of claim 4, further comprising:receive a message by a user selecting a control in the first userinterface that allows a user to toggle between a quick connect mode ofuse of the graphical user interface and a mode of use that listsproviders.
 7. An apparatus comprising: a processor; memory incommunication with the processor; and a computer program producttangibly stored on a computer readable storage device for providingbroker services to consumers and service providers, the computer programproduct comprising instructions for causing a computer to: generate afirst graphical user interface for accessing a brokerage system forproviding broker services to consumers from service providers, thegraphical user interface rendering a plurality of controls that whenselected by a consumer, sends a request to consult with a serviceprovider of a type associated with the corresponding one of theplurality of controls; send the graphical user interface to a deviceused by the consumer; receive the request; and send to the consumer asecond graphical user interface to enable the user to provideinformation to a service provider for use during a consultation with aservice provider of the type associated with the corresponding one ofthe controls.
 8. The apparatus of claim 7 wherein the types aredifferent types of providers.
 9. The apparatus of claim 7, furthercomprising: receive a message by a user selecting a control in the firstuser interface that allows a user to toggle between a quick connect modeof use of the graphical user interface and a mode of use that listsproviders.